JAWS-UGコンテナ支部 #3に参加してきた #jawsug #jawsug_ct
はじめに
今日はJAWS-UGコンテナ支部 #3に参加してきました!
場所はDeNAさんのセミナールーム。いつ来ても立派なお部屋です。
レポート
Amazon EC2 Container Service by AWSJ 岩永亮介さん (@riywo)
Amazon ECSデモ
node.jsで書かれたGeneratorがダミーのアクセスログを作成、Kinesisに投入
Pythonで書かれたConsumerがKinesisからログを取得、AWS IoTにMQTTでPublish
node.jsで書いたダッシュボードでログを表示
DevOpsのライフサイクル
開発、ビルド、テスト、プロダクション環境へのリリース。
裏でもう1つやらなくてはいけないことがある。サーバの構築。環境ごとの設定。
アプリケーションとは別にメンテし続けなくてはいけないのが結構辛い。
Dockerになると?アプリケーション、サーバ、環境設定が一まとめになっている。
Dockerの中のプロビジョニングはShellでもいい。ほとんど一回しか流さない。
一回プロビジョニングしたらあとはテスト環境にもプロダクション環境に巻くだけ。
DevOpsの流れが変わる可能性があるのがDocker。
Amazon ECS
Containerをただ起動するだけなら超簡単。管理する必要が無い。
ECSを使えば?
ホストとなるEC2の利用を効率的に行える。
ホストEC2のインスタンスタイプを分散(EC2 Spot Fleet)
Cluster管理、リソースの状況を監視し、適切に配置
Amazon ECS Update
Amazon EC2 Container Registory
もうちょっとでリリースされる、ご期待ください。
AZを意識したスケジューリング
フェールセーフな作りができる
ECS CLI
Docker Composeと連携、yamlで制御
Docker Containerの設定オプションを改善
CloudWatchメトリクスの追加
まとめ
DevOpsの改善が一番大きなメリット
クラスタ管理をECSにぶん投げると、Dockerのコンテナ管理が非常に簡単
ECRがリリースされるとレジストリ管理を考えなくて良くなる
Next FRESH! Applications with Amazon ECS by 株式会社サイバーエージェント @stormcat24さん
AmebaFRESH!
生放送動画配信プラットフォーム
12月に一般公開予定、現在クローズド公開中
スマホナイズドされたUI、オシャレなニコ生を目指している
Amazon ECSで全て稼働している
4月からプロジェクト開始、メンバー約30名
配信はRTMP Publishing、視聴側はHLS
サーバサイドは全てAWS。Go1.5 + Docker 1.9.0。
マイクロサービスアプローチを取っている。APIはRESTful(goji)
アーキテクチャー
目指していること
極力メンテを入れず運用していくことを目標
24時間何かしら配信があるような状況に持っていきたい。
ゼロダウンタイムのためのBlue-Green Devployment。
インフラは更新せず入れ替える。
素早く頻繁にどんどんリリースしていきたい
システムは疎結合、マイクロサービス。
何が使いやすいか?出した答えがコンテナ。
マイクロサービス
特定の開発言語に依存しない。使い続けると飽きる。
来年Elixirとかやるかもしれないし、Javaに戻るかもしれないし...
エンジニアのモチベーションを維持する一つの方法がマイクロサービス化かなと思っている。
通信プロトコル
RESTFul API。HTTP。
ELBがHTTPSをサポートしていないのでgRPCはまだ対応していない
マイクロサービスの粒度
タイムラインとか、システム的なドメインで切っている。
あとから切り直すのも全然ありかなと思っている。
インフラはECS
ちょうど検証中に東京リージョンに来た。
コンテナ構成管理とスケジュールがあれば運用できると判断。
他にもAWSで使いたいサービスがあった。LambdaとかAuroraとか。
実際どうやって作っているか。基本方針
マイクロサービスごとにTask Definition
1ECS Cluseterに1Service
1Clusterには1つのAutoScaling Groupが紐付いている
動画配信サーバは特殊なので例外
Taskの構成方針
Dockerを使う上で一番気をつけなきゃいけないのはログ。消失しないように。
td-agentでログを転送。各コンテナのログは、コンテナが所属するホストに吐く。
td-agentがホストのログディレクトリをマウントして、他の場所に転送
Docker 1.8からサポートされたlogging driverを使えばtd-agentがいらなくなる
が、まだ導入していない
Internal Serviceであってもログを出すのが楽なので必ずNginxを通している
1Cluster=1Serviceのデメリット
リソース効率的にはいまいち。1クラスターに複数のサービスを任せるのがベスト
リソース効率が悪いので、インスタンス数は増える傾向にある。
開発環境ではt2.microのような小さいインスタンスを有効活用。
nanoインスタンスが出てくると有効活用できそう。
1Cluster=1Serviceにしている理由
Dockerビギナーにとって視覚的に分かりやすい
サービス単位にIAM Roleで制御したいが、IAM RoleはEC2にしか割り当てられない
サービス単位でのSecurity Group→ELBを活用すればクリアできる。
Blue Green Deployment
2AutoScalingパターン
Blue、GreeのClusterを作成。
それぞれがAutoScaling Groupに所属。
AutoScaling Group単位でELBの切り替えを行う。
特徴。とても安全にデプロイできる。ロールバックも楽。
ただしデプロイ前にStandbyのウォームアップが必要。
2系統あるのでコストが嵩む。不要になったGroupは落とすなどで対処。
Diet Docker Image
イメージは小さいほど良い。Build時間もCI時間も下がる。
Registoryからのダウンロード時間も短くなる。
AutoScalingで立ち上がるサービスの起動も早くなる。
dokcer hub
たくさん公式イメージがあるが、大きいものがたくさんある。
Dockerを運用する上ではボトルネックになりがち。1GB超えるとデブ。
不要なものは削除
対処の積み重ね。不要なファイルの削除、ビルドで生じたゴミを消す。
Data Volumeを使ってホストのファイルシステムを利用→ポータビリティが落ちる
RUNの回数を減らす
Dockerは差分ビルドなので、RUNの分だけイメージのレイヤーが増える。
なるべく&&でチェインして、RUNの回数を減らすのが良い。
長いdocker buildで途中でこけるとRUNの頭から始まる→辛い。
RUNを1回でやるのがスタンダードなのかな、と思う。
軽量イメージを使う
オフィシャルでもslimイメージが用意され始めている
busybox、とても軽い
ポータビリティは高い
アプリケーションが求める環境を構築する難易度が高くなる
減量による弊害
x509問題、軽量化し過ぎて発生
コンテナからHTTPS通信ができなくなる
外部ツールに依存しすぎていると辛い
ベースイメージの作成
aptなどパッケージアップデートは時間がかかる
たまにaptが調子悪くてbuildが失敗したりする
アップデート済みのイメージを作成しておく
ローカル開発はどうやっているか
docker-machineとVirtualBox
docker-compose
docker-machine
バックエンドにDockerホストを構築する
あたかもローカルにDocker環境があるかのように操作ができる
Vagrantは捨てた。Dockerに比べると起動も遅い、プロビジョニングも辛い。使い捨てコストが高い。
アプリケーション、ミドルウェアを全部ローカルで確認できる
nginxへの通信などはVirtualBoxのポートフォワードを使う。
ローカルをフルでDockerにするとマシンリソースが必要。
ローカルPCをメモリ16GBに変更。コンテナをいっぱい立ち上げると辛い。
コンテナを立ち上げてもTwitterができるように。
docker-compose
Docker Toolboxの一部。元々figと言われていた。
DockerコンテナをYAMLで管理。
ローカルのデータストアもDockerでやっている。
MySQLやRedisなどをdocker-composeで立ち上げ。一瞬で手に入る。
DBのマイグレーション。
環境があってもデータ不備があると意味が無い。
FRESH!ではgoのgooseを使っている。SQLを時系列で並べて適用。
SQLじゃなくてGoでも書ける。
ecs-formation
docker-composeのように、YAMLでコンテナを管理。
当時はecs-cliが無かったので自作。aws-sdk-goを利用。
主な機能。Task Definitionsの更新、クラスタに配置するサービスの更新。Blue-Green Deploymentの実現。
その他のツール
AMI
EC2-Otimized AMI。Docker + ECS Agent。便利だけど社内で面倒見切れなかった。
自前のUbuntuイメージを作成。
Private Registory
CircleCI
1リポジトリに1Dockerfile。
インフラ系ミドルウェアは別のリポジトリに。
Terraform
インフラ構築のためのオーケストレーションツール
AWSでのインフラ構築で利用
EC2、SG、Route53(Internal)、ECS Cluster、AutoScaling Groupの起動構成
癖のあるツールなので、ELBなど運用によって状態が変わるものには無いていない
ビルドに時間がかかるRDSやElastiCacheにも向いてい無い
クリティカルなものは避けている(Route53、IAM)
tfstateはS3上に保持
全てを1つのtfstateで管理しない。環境によって分ける。
Mackerel
監視は基本的にMackerel。綺麗で見やすい、お気に入り。
最近Dockerのメトリクスが取れるようになった。
所感
ECSの進化が早く、ついていくのは大変だが、周辺ツールが充実してきた
全然運用できるな、という感想
やりたいと思う人はぜひやってみてほしい
最後に
サイバーエージェントさんの事例は非常に興味深かったです。Imageのダイエット方法など、とても参考になりました。
さて、これからLTタイムですが、僕はビールを飲みながらピザを食べるので特にメモは取りません!楽しみます!